Contents | Prev | Next | JDBCTM Guide: Getting Started

## Appendix B: Additional Suggestions

This section contains a list of some of the suggested additions that we received that have not been added to the JDBC API. They are listed simply as a record of some of the things that have been left out. We welcome input concerning the items listed here.

## B.1 Other Suggestions for v0.1

Processing Results - Add a way to determine the value of an auto-incremented key after an insert is done.

Enhanced Meta-Data - Add meta-data for prepared statement parameters and for prepared statement result set. The JDBC API does not provide metadata describing a prepared statements parameters; and, it does not provide metadata describing its results without executing the statement (equivalent to SQL92 DESCRIBE OUTPUT and ODBC SQLDescribeParam.

New Data Types - Add the SQL time interval data type

Security - Allow the application to choose underlying transport properties, e.g., SSL. Provide SSL Socket implementation. A JDBC technology based application must be able to select driver-supported mechanisms for securing the wirelevel protocol (e.g., encryption). Relative to SSL, one option is to allow the application to specify a specific Cyphersuite (key-exchange algorithm, bulk-encryption, MAC [message authentication algorithm])

Security-Authentication - Allow an application to select driver-supported mechanisms for performing authentication. The following mechanisms should be supported: Username, password; Kerberos token; Digital Certificates

Command Complete event - Support a user provided event object that is fired when a Command completes (both current command and regular command, sync or async). - - Various events: Connect Event; Disconnect Event; Before Connect Event

Cursor Implementation Location - Support client-side vs server-side.

Parameter Management - Support: Append, GetCount, GetItem (by name/position), Delete and Refresh.

Hybrid SQL/Java programming language Integration - Provide a mechanism for defining Java classess and provide a hybrid SQL/Java query mechanism over Tables whose columns may be SQL atomics or Java classes.

Specialty Data Types - Provide extensions for OLAP, Spatial, TimeSeries and other Specialty Data Types.

Serializing data, time, timestamps - Allow these types to be serializable.

Async Requests - Allow the caller to request that a Statement execute asynchronously.

Java classes - Introduce the notion of a SQL specialization of Java classes/beans that introduces SQL99 concepts useful for dealing with Java objects in the context of databases and business applications. For example, it is useful for a database system to understand which method(s) definitions in a Class may be used to perform operations on objects such as comparisons, etc. One approach would be to introduce "generic" method names. Those could also be used outside of the database by regular Business Applications.

Add support for SQL PSM.

Add additional SQL language functionality e.g. various forms of join.

Add *levels* of JDBC compatibility, as opposed to individual API calls to see if individual features are supported by a drvier.

Add an API call that describes the format of the URL understood by a driver.

Add a row object that encapsulates database data in its native format.

Add immutability for Date, Time, Timestamp.

## B.2 Additional suggestions for v0.7

- It was suggested that as an alternative to providing individual methods for each new property on the `Statement` interface such as result set type, concurrency type, etc., we could introduce a new Class, `ResultSetProperties`, that itself contained all methods for getting and setting these properties. Statement would then just contain two new methods for getting and setting a `ResultSetProperties` property. This approach would help to simplify the `Statement` interface.
- Add a new CursorResultSet interface which extends ResultSet and adds method `CursorStatement prepareUpdate() throws SQLException`; OR add the `prepareUpdate` method to the existing `ResultSet` interface - and define that it may fail if there is no cursor associated with it. Add a new `CursorStatement` interface which extends `PreparedStatement` and adds the methods:`void update() throws SQLException` and`void delete() throws SQLException`. It would be helpful to introduce another intermediate `CursorResultSet` which would sit in the interitance hierarchy between `ResultSet` and `ScrollableResultSet`. The motivation for the CursorStatement is to avoid the need to parse every query to look for cursor operations. The reason to have CursorStatement extend PreparedStatement is to get access to the setXXX methods. The setXXX() methods would be used to provide new values to the corresponding columns of the current row in the CursorResultSet. The executeUpdate() method would perform the actual update (with the parameter values that had been set) or delete (parameter values are ignored). The execute() and executeQuery() methods would be overridden so that they always throw SQLException. Additionally, the CursorStatement would be "bound" to the CursorResultSet which created it such that whenever that CursorResultSet was repositioned (next, relative, absolute, first, last, etc.) that the CursorStatement would automatically track this and update/delete methods affect the right row. ** It is tempting to do away with the CursorStatement and just add that functionality to the CursorResultSet because these things are likely to be in 1:1 relationship.
- Add to the `Statement` interface: `void setCursorProperties(CursorProperties props) throws SQLException`; Define a new `java.sql.CursorProperties` class. I like the idea of adding statement properties so that appropriate subclasses of `ResultSet` are returned when the statement is executed. But, rather than adding a bunch of individual accessors/mutators for all these properties to `Statement`, I would recommend defining a `CursorProperties` class with public members and then add just a single new method to `Statement`: `void setCursorProperties(CursorProperties props) throws SQLException`; This would remove the need for the new `Statement.setFetchSize` and `getFetchSize` methods for example. `CursorProperties` would have a public constructor which returns a `CursorProperties` object with well defined default values (TBD). Members of this class would include: 0. boolean useCursors - if true the statement should return a `CursorResultSet` from executeQuery. 1. String cursorName - `Statement.setCursorName()` would be depricated. 2. boolean scrollable - if true the statement should return a `ScrollableResultSet` from execute query. 3. boolean readonly - if true this cursor is READONLY. 4. int rowCacheSize - hint to driver on how many rows to retrieve from the database at a time. 5. boolean closeOnEndTransaction - in ANSI SQL '92 cursors are automatically closed on commit/rollback, but many databases allow cursors to remain open for efficiency 6. String[] updatableColumns - list of columns which in SQL '92 grammar would be in the "FOR UPDATE OF <column list>" clause. 7. boolean sensitive - if true committed changes to the underlying tables which happened while the cursor was open may be seen by the application as it scrolls over those rows.
- The result of any SQL query can be thought of as defining a simple structured type. The fields of the structured type correspond to the columns of the query result, and each row in the result set returned by the query represents an instance of the type. The JDBC API could allow a mapping from a type that is defined implicitly by an SQL query to a Java class, or even a bi-directional mapping between regular relational tables and Java classes.

Contents | Prev | Next

Copyright © 1996-1999 Sun Microsystems, Inc. All rights reserved.